Troubleshooting Crashes, ANRs, and Common Application Defects in Android

Course: Android App Development

Topic: Troubleshooting Crashes, ANRs, and Common Application Defects

Course Link: Android App Development Training

Demo Link: Register for a Course Demo

Website: JustAcademy

1. Introduction to Android Application Troubleshooting

Android application troubleshooting is the process of identifying, analyzing, and resolving problems that affect an application's functionality, performance, stability, and user experience. During development, applications may crash unexpectedly, become unresponsive, display incorrect information, consume excessive memory, or fail to communicate with external services.

Android developers use tools such as Android Studio, Logcat, the debugger, Android vitals, and system diagnostic reports to investigate these problems. Effective troubleshooting requires understanding the symptoms, collecting useful evidence, identifying the root cause, implementing a fix, and testing the application again.

Three important areas of troubleshooting are:

• Application crashes: Unexpected termination caused by an unhandled exception, fatal error, or other runtime failure.
• Application Not Responding (ANR): A condition in which the application fails to respond to certain user or system events within the expected time.
• Common application defects: Functional, visual, performance, lifecycle, networking, and data-related problems that prevent the application from behaving correctly.

2. Learning Objectives

• Understand Android application crashes and their common causes.
• Identify ANR conditions and understand how they occur.
• Analyze Logcat output and crash stack traces.
• Use Android Studio debugging tools to locate defects.
• Troubleshoot null pointer exceptions and other runtime errors.
• Identify main-thread blocking, memory leaks, and performance bottlenecks.
• Investigate network failures, lifecycle defects, and UI problems.
• Apply systematic testing and prevention techniques.

3. Understanding Android Application Crashes

An application crash occurs when an app cannot continue normal execution because of a fatal runtime error or another failure that terminates its process. Crashes may happen during application startup, screen navigation, user interaction, background processing, or communication with external services.

Common Symptoms of Crashes

• The application suddenly closes.
• The user returns to the home screen unexpectedly.
• An error message appears when opening a particular screen.
• The application repeatedly crashes after startup.
• A button or action causes the application to terminate.
• The application works on one device but crashes on another.

Common Causes of Application Crashes

4. Understanding ANR (Application Not Responding)

ANR stands for Application Not Responding. Android may report an ANR when an application fails to respond to important input or system events within the expected time. The operating system may display a dialog informing the user that the application is not responding.

ANRs are commonly associated with a blocked main thread, which is responsible for processing UI events, handling input, and coordinating interface updates. If this thread remains occupied by a long-running operation, the application may become unresponsive.

Common Causes of ANRs

• Performing lengthy calculations on the main thread.
• Making synchronous network requests from the UI thread.
• Reading or writing large files on the main thread.
• Executing slow database operations during UI interactions.
• Waiting indefinitely for a lock or another thread.
• Deadlocks between threads.
• Excessive work during activity startup or screen rendering.
• Slow input event processing or expensive broadcast receiver operations.

Crash vs. ANR

A crash and an ANR are different types of failure, although the same underlying defect can sometimes contribute to both.

5. Using Logcat to Identify Application Problems

Logcat is an Android logging tool that displays messages generated by the Android system, application code, and runtime components. It helps developers locate exceptions, lifecycle events, failed operations, warnings, and other diagnostic information.

Steps to Use Logcat

1. Open the project in Android Studio.
2. Connect an Android device or start an emulator.
3. Run the application.
4. Open the Logcat tool window.
5. Select the appropriate device and application process.
6. Reproduce the issue while observing the output.
7. Search for terms such as FATAL EXCEPTION, AndroidRuntime, or a relevant exception class.
8. Inspect the stack trace to identify the code path associated with the failure.
9. Fix the suspected cause and reproduce the same scenario to verify the result.

Example of Logging an Error

import android.util.Log

class LoginRepository {
    fun validateUsername(username: String): Boolean {
        Log.d("LoginRepository", "Validating username")
        return username.isNotBlank()
    }
}

The Log.d() method records a debug-level message. Developers can use logging to understand the execution flow, but should avoid including passwords, access tokens, personal information, or other sensitive data in logs.

6. Reading and Understanding Stack Traces

A stack trace shows the sequence of method calls associated with an exception. It is one of the most useful resources for diagnosing crashes.

Example

java.lang.NullPointerException:
    Attempt to invoke a method on a null object reference
    at com.example.myapp.ProfileActivity.loadProfile(ProfileActivity.kt:42)
    at com.example.myapp.ProfileActivity.onCreate(ProfileActivity.kt:25)

This simplified example indicates that a null-related failure occurred in loadProfile() at line 42. The method was called from onCreate() at line 25.

How to Analyze a Stack Trace

1. Identify the exception type.
2. Read the exception message for clues about the failure.
3. Locate the first relevant stack frame in your application code.
4. Open the indicated source file and inspect the reported line.
5. Trace backward to understand where the input or object originated.
6. Check whether the failure depends on device state, timing, user input, or a particular data set.
7. Implement a fix and confirm it through testing.

Do not automatically assume that the last visible line in a stack trace contains the root cause. The actual problem may originate from an earlier method call or invalid data passed into that method.

7. Troubleshooting Null Pointer Exceptions

A Null Pointer Exception occurs when code attempts to perform an operation on a null reference that does not support that operation. Kotlin's null-safety features help prevent many such errors, but null-related failures can still occur through Java interoperability, platform types, unsafe assertions, or incorrect application logic.

Problematic Example

fun displayName(name: String?) {
    val length = name!!.length
    println("Name length: $length")
}

The expression name!! asserts that the value is not null. If name is null, the application throws a runtime exception.

Safer Example

fun displayName(name: String?) {
    val safeName = name ?: "Guest"
    val length = safeName.length

    println("Name: $safeName")
    println("Name length: $length")
}

This version uses the Elvis operator to provide a fallback value when the input is null.

Prevention Techniques

• Use nullable and non-nullable types correctly.
• Validate data received from APIs and external sources.
• Avoid unnecessary use of the non-null assertion operator.
• Check object initialization and lifecycle state.
• Use safe calls when a value may legitimately be absent.
• Write tests for missing and incomplete data.

8. Troubleshooting Index and Collection Errors

Index errors occur when code accesses an array or collection using a position outside its valid range. They often arise when lists are empty, data changes unexpectedly, or a loop uses an incorrect boundary.

Problematic Example

fun printFirstItem(items: List<String>) {
    println(items[0])
}

If items is empty, accessing index 0 throws an IndexOutOfBoundsException.

Safer Example

fun printFirstItem(items: List<String>) {
    val firstItem = items.firstOrNull()

    if (firstItem != null) {
        println(firstItem)
    } else {
        println("No items available")
    }
}

When troubleshooting collection defects, inspect the collection size, index values, loop boundaries, and any changes made to the collection during processing.

9. Troubleshooting Main-Thread Blocking

The main thread is responsible for processing UI interactions and coordinating interface work. Long-running operations on this thread can prevent the application from responding promptly.

Problematic Example

fun loadData() {
    Thread.sleep(5000)
    // UI interactions cannot be processed normally
    // while the main thread is blocked.
}

If this function executes on the main thread, the artificial five-second delay prevents normal event processing during that period.

Using a Coroutine for Background Work

class DataViewModel : ViewModel() {

    fun loadData() {
        viewModelScope.launch {
            val result = withContext(Dispatchers.IO) {
                fetchDataFromStorage()
            }

            // Update UI state on the main dispatcher.
            // Publish result to the UI here.
        }
    }

    private fun fetchDataFromStorage(): String {
        return "Data loaded"
    }
}

This example illustrates moving blocking I/O work to an appropriate background dispatcher. In a real application, ensure that the operation is actually performed by the I/O block, handle failures, and expose the result through observable UI state as needed.

Ways to Prevent ANRs

• Move lengthy file, database, and network operations off the main thread.
• Use Kotlin coroutines or another suitable concurrency mechanism.
• Avoid synchronous waits for background tasks.
• Investigate thread locks and possible deadlocks.
• Reduce expensive work during activity startup.
• Keep broadcast receiver processing brief and schedule longer work appropriately.
• Use profiling and system traces to find slow operations.

10. Troubleshooting Memory Problems and Memory Leaks

Memory-related defects occur when an application uses excessive memory, retains objects unnecessarily, or fails to release references to objects that are no longer needed. Severe memory pressure can degrade performance and may eventually cause the application to be terminated.

Common Symptoms

• Slow scrolling and delayed screen transitions.
• Increasing memory usage over time.
• Repeated garbage collection and temporary pauses.
• Out-of-memory exceptions.
• Large image loading failures.
• Objects remaining in memory after a screen is closed.

Common Causes

• Holding references to activities or views longer than necessary.
• Keeping large bitmaps in memory.
• Registering listeners without unregistering them when required.
• Using unbounded caches or collections.
• Retaining objects through long-lived singleton instances.
• Launching background work that unnecessarily retains UI objects.

Troubleshooting Steps

1. Open Android Studio's Memory Profiler.
2. Reproduce the suspected memory issue.
3. Observe memory usage during screen navigation and repeated operations.
4. Capture and inspect heap dumps when appropriate.
5. Look for objects that remain reachable unexpectedly.
6. Review activity, fragment, listener, and coroutine lifecycles.
7. Release unnecessary references and bound caches.
8. Repeat the test to confirm that memory usage behaves as expected.

11. Troubleshooting Network-Related Defects

Network defects can cause failed logins, incomplete data, repeated loading indicators, timeouts, and unexpected error screens. They may result from connectivity problems, server failures, invalid responses, incorrect request parameters, or insufficient error handling.

Common Network Problems

Example of Handling a Network Failure

suspend fun loadProfile(): Result<String> {
    return try {
        val profile = fetchProfileFromApi()
        Result.success(profile)
    } catch (exception: IOException) {
        Result.failure(exception)
    }
}

This simplified example converts an I/O failure into a result that the calling code can handle. Production code should also handle relevant HTTP errors, parsing failures, cancellation, and other expected exceptions appropriately. It should not silently hide unexpected programming errors.

12. Troubleshooting Activity and Fragment Lifecycle Defects

Android components have lifecycles that determine when they are created, started, resumed, paused, stopped, and destroyed. Defects can occur when an application performs operations at the wrong lifecycle stage or retains outdated references.

Common Lifecycle Problems

• Updating a view after its fragment view has been destroyed.
• Retaining an activity reference in a long-lived object.
• Repeating API requests after configuration changes.
• Losing temporary UI state during screen rotation.
• Registering observers or listeners multiple times.
• Launching work that continues unnecessarily after the screen closes.

Troubleshooting Approach

1. Use Logcat to observe lifecycle callback sequences.
2. Set breakpoints in relevant lifecycle methods.
3. Inspect the call stack when an unexpected callback occurs.
4. Review the lifetime of observers, listeners, and background operations.
5. Use lifecycle-aware components and state holders where appropriate.
6. Test screen rotation, backgrounding, returning to the app, and process recreation.

Lifecycle-aware design helps ensure that UI updates and background operations respect the lifetime of their associated components.

13. Troubleshooting UI Rendering and Interaction Defects

UI defects affect how users view or interact with the application. They may occur because of incorrect layouts, overlapping views, inefficient rendering, missing resources, or incorrect event handling.

Examples of UI Defects

• Buttons do not respond to taps.
• Text is clipped or overlaps other views.
• Lists scroll slowly.
• Content is missing on specific screen sizes.
• Keyboard appearance hides important controls.
• Screen content is not refreshed after a data update.
• Touch targets are difficult to select.

Tools and Techniques

• Use Layout Inspector to examine the view hierarchy.
• Set breakpoints in click listeners and UI state updates.
• Use Logcat to check for resource or layout-related errors.
• Profile rendering performance when frames are slow.
• Test different screen sizes, orientations, and Android versions.
• Verify that UI updates occur on the appropriate thread.

14. Troubleshooting Database and Data Persistence Defects

Database defects may lead to missing records, duplicated entries, failed queries, incorrect sorting, or application crashes. These problems can result from invalid SQL, schema changes, concurrent access, incorrect transactions, or unexpected data.

Common Database Problems

For Android applications using Room, review entity definitions, DAO queries, migration logic, and transaction boundaries. Test both fresh installations and upgrades from previous database versions.

15. Using Android Studio Debugging Tools

Android Studio includes several tools that help developers diagnose different classes of defects.

Tool availability and specific capabilities may vary by Android Studio version, Android version, device configuration, and application build type.

16. A Systematic Troubleshooting Workflow

Following a consistent process helps prevent guesswork and makes defects easier to reproduce and fix.

1. Identify the symptom: Determine whether the issue is a crash, ANR, incorrect result, performance problem, or UI defect.
2. Reproduce the problem: Record the steps, device, Android version, application version, and relevant input data.
3. Collect evidence: Review logs, stack traces, ANR diagnostics, profiler data, or server responses.
4. Locate the failure: Use breakpoints, call stacks, and targeted logging to narrow the problem area.
5. Form a hypothesis: Identify the most likely cause using the collected evidence.
6. Implement a focused fix: Correct the underlying defect rather than masking its symptoms.
7. Test the fix: Repeat the original reproduction steps and test related scenarios.
8. Run regression tests: Confirm that existing features still behave correctly.
9. Monitor production behavior: Use crash reporting and performance metrics to detect recurring issues.
10. Document the resolution: Record the root cause, fix, and prevention measures.

17. Preventing Future Crashes and ANRs

Prevention is more efficient than repeatedly responding to failures after release. Good coding practices, automated tests, and continuous monitoring improve application stability.

Recommended Practices

• Validate user input and external data.
• Handle expected exceptions at appropriate boundaries.
• Keep blocking operations off the main thread.
• Use lifecycle-aware components and structured concurrency.
• Avoid retaining activities, fragments, and views unnecessarily.
• Test network failures, empty responses, and slow connections.
• Use unit tests for business logic and integration tests for component interactions.
• Test on multiple Android versions and screen configurations.
• Review crash reports and ANR trends after releases.
• Use staged rollouts when appropriate to reduce release risk.
• Keep dependencies updated and verify compatibility before upgrades.
• Maintain clear error handling and safe diagnostic logging.

18. Practical Exercise: Diagnose and Fix an Application Defect

Objective: Practice identifying a crash, inspecting the source of the error, and implementing a safer solution.

Problematic Code

fun calculateAverage(numbers: List<Int>): Double {
    val total = numbers.sum()
    return total.toDouble() / numbers.size
}

The code does not check whether the list is empty. When the list contains no values, the calculation divides zero by zero, producing a non-finite floating-point result rather than necessarily causing an application crash.

Improved Code

fun calculateAverage(numbers: List<Int>): Double? {
    if (numbers.isEmpty()) {
        return null
    }

    val total = numbers.sum()
    return total.toDouble() / numbers.size
}

Tasks

1. Run the original function with a non-empty list.
2. Test it with an empty list and observe the result.
3. Set a breakpoint before the division operation.
4. Inspect the list size and total.
5. Implement the improved function.
6. Test with positive numbers, negative numbers, and an empty list.
7. Verify that the UI handles the null result appropriately.
8. Add unit tests to prevent the defect from returning.

Expected Results

Learning outcome: Understand how to reproduce a defect, inspect intermediate values, improve input handling, and verify the corrected behavior.

19. Interview Questions and Answers

Q1. What is an Android application crash?

An application crash occurs when a fatal runtime error or another failure causes the application process to terminate unexpectedly.

Q2. What is an ANR?

An ANR is an Application Not Responding condition in which an application fails to respond to important input or system events within the expected time.

Q3. What is the main difference between a crash and an ANR?

A crash generally terminates the application, whereas an ANR indicates that the application is not responding promptly to events.

Q4. What is Logcat used for?

Logcat displays application and system messages that help developers investigate exceptions, warnings, execution flow, and other runtime problems.

Q5. What is a stack trace?

A stack trace lists method calls associated with an exception and helps developers locate the code path where a failure occurred.

Q6. How can developers prevent ANRs?

They can move long-running operations off the main thread, avoid blocking waits, reduce expensive UI work, and investigate thread contention.

Q7. What is a memory leak?

A memory leak occurs when objects remain reachable and occupy memory even though the application no longer needs them.

Q8. How can a developer investigate an OutOfMemoryError?

Use memory profiling and heap analysis to identify large allocations, retained objects, oversized images, and unbounded caches.

Q9. Why is reproducing a defect important?

Reproducing the defect provides a consistent way to gather evidence, isolate the root cause, and verify that the fix works.

Q10. What is regression testing?

Regression testing checks that a new fix or change has not broken features that previously worked correctly.

Q11. How can Android developers monitor production crashes?

They can review Android vitals and use suitable crash-reporting tools to monitor error frequency, affected versions, and recurring stack traces.

Q12. Why should exceptions not simply be ignored?

Ignoring exceptions can hide defects, leave application state inconsistent, and make failures more difficult to diagnose. Expected errors should be handled deliberately and unexpected errors should remain observable through appropriate diagnostics.

20. Quick Revision Checklist

• Understand the difference between crashes and ANRs.
• Use Logcat to identify runtime errors.
• Read stack traces and locate relevant source lines.
• Check null values and collection boundaries.
• Move blocking work away from the main thread.
• Investigate memory usage and retained objects.
• Validate API responses and database operations.
• Review activity and fragment lifecycle handling.
• Use Android Studio profilers and debugging tools.
• Write regression tests after fixing defects.
• Monitor crash and ANR reports after deployment.

21. Conclusion

Troubleshooting crashes, ANRs, and common application defects is an essential skill for Android developers. Understanding runtime exceptions, analyzing stack traces, inspecting variables, and profiling application performance helps developers locate the real cause of a problem instead of relying on guesswork.

By following a systematic troubleshooting workflow, keeping expensive work off the main thread, managing memory carefully, validating external data, and testing fixes thoroughly, developers can build more stable, responsive, and reliable Android applications.

Learn Android App Development with JustAcademy

Explore Android development concepts and strengthen your practical programming skills through structured learning.

Explore the Android App Development Course

Register for a Course Demo

Visit the JustAcademy Website